Data security using request-supplied keys

ABSTRACT

An encoding of a cryptographic key is obtained in a form of an encrypted key. Request is provided to a service provider including a fulfillment involving performing a cryptographic operation on data. Upon fulfillment of the request, a response is then received which indicates the fulfillment of the request.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/090,315, filed on Apr. 4, 2016, issued as U.S. Pat. No. 10,037,428,entitled “DATA SECURITY USING REQUEST-SUPPLIED KEYS,” which is acontinuation of U.S. patent application Ser. No. 14/037,292, filed onSep. 25, 2013, entitled “DATA SECURITY USING REQUEST-SUPPLIED KEYS,”issued as U.S. Pat. No. 9,311,500, the content of which are incorporatedby reference herein in their entirety. This application alsoincorporates by reference for all purposes the full disclosure of U.S.patent application Ser. No. 14/037,282, filed Sep. 25, 2013, issued asU.S. Pat. No. 9,237,019, entitled “RESOURCE LOCATORS WITH KEYS.”

BACKGROUND

The security of computing resources and associated data is of highimportance in many contexts. As an example, organizations often utilizenetworks of computing devices to provide a robust set of services totheir users. Networks often span multiple geographic boundaries andoften connect with other networks. An organization, for example, maysupport its operations using both internal networks of computingresources and computing resources managed by others. Computers of theorganization, for instance, may communicate with computers of otherorganizations to access and/or provide data while using services ofanother organization. In many instances, organizations configure andoperate remote networks using hardware managed by other organizations,thereby reducing infrastructure costs and achieving other advantages.With such configurations of computing resources, ensuring that access tothe resources and the data they hold is secure can be challenging,especially as the size and complexity of such configurations grow.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments in accordance with the present disclosure will bedescribed with reference to the drawings, in which:

FIG. 1 shows an illustrative example of an environment in which variousembodiments can be implemented;

FIG. 2 shows an illustrative example of an environment in which variousembodiments can be implemented;

FIG. 3 shows an illustrative example of a representation of a request inaccordance with at least one embodiment;

FIG. 4 shows an illustrative example of a process for submitting arequest in accordance with at least one embodiment;

FIG. 5 shows an illustrative example of a process for processing arequest in accordance with at least one embodiment;

FIG. 6 shows an illustrative example of a representation of a request inaccordance with at least one embodiment;

FIG. 7 shows an illustrative example of a process for processing a PUTrequest in accordance with at least one embodiment;

FIG. 8 shows an illustrative example of a process for submitting a GETrequest in accordance with at least one embodiment;

FIG. 9 shows illustrative examples of a representations of requests inaccordance with various embodiments;

FIG. 10 shows an illustrative example of a process for submitting arequest in accordance with at least one embodiment;

FIG. 11 shows an illustrative example of an environment in which variousembodiments can be implemented;

FIG. 12 shows an illustrative example of a process for processing arequest in accordance with at least one embodiment;

FIG. 13 shows an illustrative example of an environment in which variousembodiments can be implemented;

FIG. 14 shows an illustrative example of a process for processing arequest in accordance with at least one embodiment; and

FIG. 15 illustrates an environment in which various embodiments can beimplemented.

DETAILED DESCRIPTION

In the following description, various embodiments will be described. Forpurposes of explanation, specific configurations and details are setforth in order to provide a thorough understanding of the embodiments.However, it will also be apparent to one skilled in the art that theembodiments may be practiced without the specific details. Furthermore,well-known features may be omitted or simplified in order not to obscurethe embodiment being described.

Techniques described and suggested herein relate to the submission andprocessing of requests where the requests include cryptographic keys.The requests may be generated by and submitted from customers of aservice provider, such as a computing resource service provider.Processing the requests may include use of the keys included in therequests to perform one or more cryptographic operations such asencryption, decryption and generation of electronic (digital) signatureson data. In some embodiments, the techniques described and suggestedherein are used to enable server-side encryption (and/or relatedtechniques such as decryption) where the key to be used forencryption/decryption is controlled by the client (i.e. device of thecustomer or operating on behalf of the customer).

In various embodiments, use of keys provided in requests is performed sothat, except for a limited time during which the keys are used, theservice provider lacks access to the key. For example, the serviceprovider may operate a data storage service. A customer may transmitdata to the service provider for storage by the data storage service. Arequest to the service provider may include a key to be used to encryptthe data. The service provider may obtain the key from the request anduse the key to encrypt the data so that the encrypted data may bepersistently stored using the data storage service. When the key is nolonger needed (e.g., when encryption of the data has completed), theservice provider may perform one or more operations to lose access tothe key, such as by destroying or allowing to be destroyed any in-memorycopies of the key. Any copies of the data in plaintext form maysimilarly be destroyed or allowed to be destroyed. Once the key andplaintext data has been destroyed, the customer can be assured that theprovider is unable to decrypt the data. Thus, even if a security breachor other event at the provider causes access to the data not authorizedby the customer, the breach by itself does not enable access to the datain plaintext form.

Keys may be provided in requests in various ways in accordance withdifferent embodiments. For example, in some embodiments, the requestincludes the key in plaintext form. The plaintext key may be a symmetrickey to be used in a symmetric key algorithm. The plaintext key may alsobe a public key of a public-private key pair for an asymmetric keyalgorithm, where the service provider lacks access to the private key ofthe key pair and the private key is accessible to an entity to be ableto decrypt using the private key (e.g., the customer). In someembodiments, requests include keys in encrypted (wrapped) form. Forexample, the key may be encrypted so as to be decryptable by the serviceprovider or another entity at the direction of the service provider. Thekey used to encrypt the key in the request may be a secret shared withan entity able to decrypt the key (e.g., service provider) or a publickey of a public-private key pair where the private key is to be used byan entity to decrypt the encrypted key for processing the request.

Upon receipt of a request with a key, the service provider may accessthe key from the request, decrypting or causing to be decrypted, ifapplicable, and then process the request. Other operations may beperformed, such as by verifying an electronic signature of the requestor checking whether fulfillment of the request is in compliance with anyapplicable policy. Other details of operations that may be performed arediscussed in more detail below.

FIG. 1 shows an illustrative example of an environment 100 in whichvarious embodiments can be implemented. In the environment 100 acustomer 102 transmits a request 104 to a service provider 106. Thecustomer 102, for example, may utilize services of the service provider106. The service provider may provide any type of service relating todata which may be utilized by customers. Example services include datastorage services, database services, services that process data andothers. To submit a request 104 to the service provider 106 the customer102 may transmit the request with the aid of one or more devices of thecustomer, such personal or laptop computers, mobile devices, tabletcomputing devices, electronic book readers and/or others as described inmore detail below in connection with FIG. 15. In addition, the request104 may be submitted in accordance with one or more automated processesof the customer 102. For example, request 104 may be transmitted as aresult of a human operator of a device of the customer 102 havinginteracted with a browser or other application on a device of thecustomer 102. The request 104 may be an electronic request transmittedover a network, such as the Internet or any other network or combinationof networks discussed below. In some embodiments, for example, therequest 104 is a web service request to a web service interface providedby the service provider 106. Generally, the request 104 may beconfigured in accordance with various protocols by which requests may beelectronically submitted.

As illustrated in FIG. 1, the request 104 includes data 108 and acryptographic key 110. The data may include various types of informationand may be formatted various ways in accordance with variousembodiments. For example, in some embodiments, the data is organized asa file, such as a media file. Data may also be formatted in other ways.The data may be, for instance, organized for inclusion in a database orotherwise. The cryptographic key 110, as discussed in more detail below,may be a key used to encrypt the data 108 or otherwise to perform one ormore cryptographic operations on data. It should be noted, as will bediscussed in more detail below, that the request 104 may also includethe cryptographic key 110 in various ways. For example, in someembodiments, the request 104 includes the cryptographic key 110 inplaintext form. In other embodiments, the request 104 includes thecryptographic key in encrypted form. For example, as discussed in moredetail below, the cryptographic key 110 may be encrypted by another keysuch that the service provider 106 or another system associatedtherewith is able to decrypt the encrypted cryptographic key 110. Inthis manner, upon submission of the request 104 from the customer 102 tothe service provider 106, the service provider 106 may use thecryptographic key 110 to encrypt the data 108 received in the request104 thereby generating encrypted data 112.

The encrypted data 112 may then be stored in a data storage system 114.The data storage system 114 while illustrated as separate from theservice provider 106 may be a subsystem of the service provider 106. Forexample, the request 104 may be submitted to a web server of the serviceprovider 106 where the web server is configured to allow access to thedata storage system 114. Generally, the data storage system 114 may beoperated as a service to customers such that customers can use resourcesof the service provider 106 for the purpose of storing data. Otherembodiments also include those in which the data storage system 114 isseparate from the service provider 106. The data storage system 114 may,for example, be operated by an entity that is a third party to theservice provider 106 and the customer 102, or in some embodiments thedata storage system 114 may be a subsystem of the customer 102; that is,a subsystem of a system of the customer 102. It should be noted thatterms such as “customer” and “service” provider can have multiplemeanings and such meanings are clear from context. For example, the term“customer” may refer to an entity (e.g., a legal entity such as anorganization or individual) or a system (e.g., computing device ornetwork of computing devices) that support operations of a customerentity. Similarly, the term “service provider” may refer to a legalentity or a system supporting operations of a service provider entity.

As illustrated in FIG. 1, upon encryption of the data 108 to generatethe encrypted data 112, the service provider 106 may take one or moreactions that cause the service provider 106 to lose access to thecryptographic key 110. This is illustrated in FIG. 1 as the serviceprovider 106 passing the cryptographic key 110 to an icon labeled astrash. It should be noted that while passing the cryptographic key 110into trash as illustrated in the figure for the purpose of illustration,various embodiments may take action to lose access to the cryptographickey 110 that do not necessarily involve the transmission of thecryptographic key 110. For example, in some embodiments, upon receipt ofthe request 104 and use of the cryptographic key 110 the serviceprovider 106 may perform one or more operations to destroy thecryptographic key 110. Destruction of the cryptographic key 110 may beperformed in various ways in accordance with various embodiments. Forexample, in some embodiments, the cryptographic key 110 and request 104are not persistently stored by the service provider 106 but aremaintained in volatile memory of a device of a service provider 106.

Destruction of the cryptographic key 110 may be performed by allowingone or more memory locations that store the cryptographic key 110 to beoverwritten with other data, such as data received as part of subsequentrequests. Other operations may also be performed. For example, if thecryptographic key 110 is stored in volatile or nonvolatile memory, thecryptographic key 110 may be destroyed by overwriting (e.g., via one ormore write operations intended to destroy the cryptographic key) one ormore memory locations used to store the cryptographic key 110 with otherdata such as random data or nonrandom data such as a string of zeros.Generally, any operations that will cause the service provider 106 tolose access to the cryptographic key 110 may be used. In this manner,the customer 102 is able to submit requests to the service provider 106with cryptographic keys that the customer 102 desires to be used toencrypt data 108. Further, because the service provider 106 is, invarious embodiments, configured to lose access to the cryptographic key110 after use of the cryptographic key 110, the customer 102 can beassured that the service provider, upon processing the request 104, isunable to access the data 108 by decrypting the decrypted data 112. Inother words, the security of the data 112 is ultimately controlled bythe customer 102 with the service provider 106 having access to the datafor a limited time.

It should be noted that while various processes resulting in encrypteddata (and corresponding decrypting data) are used throughout for thepurpose of illustration, the various processes may vary in accordancewith other embodiments. For example, example processes for encryptionillustrated herein show encryption using a key supplied by a customer ofa service provider and where encryption is performed such that after anamount of time the service provider loses access to the key that wasused. However, more complex schemes may also be used where more than onekey is used to control access to data. For example, referring to FIG. 1,in some embodiments, data may be encrypted using both a key supplied bythe customer in a request as well as a key held by or otherwiseaccessible to the service provider. In this manner, coordinated actionbetween the customer 102 and the service provider 106 is required foraccess to the data 108 by way of having an ability to decrypt theencrypted data. In some embodiments, for example, the data 108 may beencrypted with one key and then again encrypted with another key. Inother examples, the cryptographic key 110 may be combined with anotherkey to generate yet another key used to encrypt the data 108. Suchvariations may also be extended to multiple parties in addition to thecustomer 102 and the service provider 106 so that generally coordinatedaction by a plurality of entities is required for legitimate access todata that has been encrypted, that is to the data in plaintext form.Other variations are also considered as being within the scope of thepresent disclosure.

In addition, while various embodiments described herein illustraterequests that have certain types of data, requests may include othertypes of data. For example, requests my include data for variousparameters of the request which may be used by a service provider todetermine if, and/or how to, fulfill a request. Generally, requests asdiscussed herein are simplified for the purpose of illustration. Therequests may, for instance, include various contextual data such as anidentity of a requestor, a network address from which the requestoriginates, an identity of an entity that generated some or all of therequest and/or other types of data.

Further, it should also be noted, that while FIG. 1 shows the request104 having data 108 to be encrypted, requests within the scope of thepresent disclosure do not necessarily have data to be encrypted. Forexample, in some embodiments the requests may have a reference to data(e.g., an identifier of a data object, which may be in the form of aURL) that is not necessarily included in the request. Processing such arequest may include using the reference to obtain the data. As anotherexample, some requests may lack data because the requests includeretrieval of data as one or more requested operations. A request toretrieve data may include a cryptographic key, but the data may bestored in another location. Processing the request may include accessingencrypted data to decrypt using the cryptographic key provided in therequest. Other variations are also considered as being within the scopeof the present disclosure.

FIG. 2 shows an illustrative example of an environment of a serviceprovider 200 in accordance with various embodiments. As illustrated inFIG. 2, the service provider 200 includes a customer interface 202. Thecustomer interface may be a subsystem of the service provider 200 whichallows for the submission of requests from customers to be processed bythe service provider 200 such as described above in connection withFIG. 1. The customer interface may accordingly include appropriatecomputing devices for providing the ability for customers to submitrequests to the service provider 200. This customer interface, forexample, may include one or more web servers configured to receiverequests over the interne or another network. While not illustrated assuch, other infrastructure may also be included in the customerinterface 202, such as appropriate networking equipment that enable thecustomer interface 202 to operate suitably for the customer of theservice provider 200.

When a request is received through the customer interface 202, therequest may be received with appropriate authenticating information. Forexample, as illustrated in FIG. 2, a request 204 may be received with asignature 206 of the request. The signature may be generated inaccordance with various embodiments. For example, a customer thatsubmitted the request 204 may generate the signature 206 using secretinformation shared between the customer and the service provider 200. Asanother example, a customer may have used an asymmetric digitalsignature scheme to sign the request 204 using a private key of aprivate/public key pair. Generally, any type of information which isused to authenticate the request 204 may be used and, in someembodiments, requests may be submitted without such information.Further, in some embodiments, the electronic signature of a request isgenerated using a cryptographic key that is different than acryptographic key supplied in the request, although in some embodiments,the electronic signature is generated using the same key that issupplied in the request.

As illustrated in FIG. 2, however, when a request 204 is receivedthrough the customer interface 202, the request 204 is provided (e.g.,over an internal network of the service provider 200) with the signature206 to an authentication system 208 of the service provider 200.Alternatively, a portion of the request sufficient for generating theelectronic signature 206 may be provided instead of the whole request.The authentication system 208 may be a subsystem of the service provider200 configured to authenticate requests such as by verifying electronicsignatures provided with requests. Upon verifying the signature 206 ofthe request 204 the authentication system 208 may provide a response tothe customer interface 202 that indicates whether the signature 206 isvalid. A device of the customer interface 202 may use the informationprovided by the authentication system 208 in order to determine how toprocess the request 204. For example, if the authentication system 208indicates that the signature 206 is invalid, the customer interface 202may deny the request. Similarly, if the information from authenticationsystem 208 indicates that the signature 206 of the request 204 is valid,the customer interface 202 may cause the request 204 to be processed.

While not illustrated in the figure, the authentication system 208 oranother system operating within or on behalf of the service provider 200may operate to perform other operations in connection with determininghow to process requests. For example, the authentication system 208 oranother system operating in cooperation therewith may be used to checkone or more policies which may be determinative of whether the requestcan be fulfilled. Policy determinations may be made based at least inpart on various factors such as an identity of the requestor thatsubmitted the request, a time of day, a logical identifier for alocation in which data is stored or is to be stored and other contextualinformation. Policy may be managed through the customer interface 202 oranother interface through appropriately-configured applicationprogramming interface (API) calls.

Returning to the embodiment illustrated in FIG. 2, if the authenticationsystem 208 determines that the signature 206 is valid, the customerinterface 202 may determine to process the request. Processing therequest may involve the transfer of encrypted data 210 between thecustomer interface 202 and request processing infrastructure 212. Therequest processing infrastructure 212 may comprise one or more devicesthat collectively operate to provide a service of the service provider200. For example, as illustrated in FIG. 2, the request processinginfrastructure may comprise a plurality of data storage system 214 usedto store data on behalf of customer of the service provider 200. Otherinfrastructure including networking infrastructure while not illustratedmay also be included. The passage of data, e.g., over a network betweenthe customer interface 202 and the request processing infrastructure 212may occur in various ways in accordance with various embodiments inaccordance with the various types of requests that may be submittedthrough the customer interface 202. For example, if the request 204 is arequest to store data, a customer interface may utilize a key providedin the request 204 to encrypt the data and transmit the encrypted data210 to the request processing infrastructure 212 for storage in one ormore of the data storage systems 214.

Similarly, if the request 204 is a request to retrieve data, a customerinterface 202 may transmit a communication to the request processinginfrastructure 212 that allows data from one or more of the data storagesystems 214 to be provided to the customer interface 202. The customerinterface 202 may then use a key provided in the request 204 to decryptthe encrypted data 210 and provide the decrypted data to the customerthat submitted the request 204. It should be noted that the environmentof the service provider 200 illustrated in FIG. 2 is simplified for thepurpose of illustration and that numerous other devices and subsystemssuch as accounting systems that keep track of usage of the serviceprovider 200 by customers may also be included. Further, a serviceprovider 200 may include facilities located in different geographicallocations for the purpose of redundancy and/or availability.

FIG. 3 shows an illustrative example of a request 300 in accordance withvarious embodiments, where the request may be a request such asdescribed above in connection with FIGS. 1-2. As illustrated in theexample shown in FIG. 3, the request 300 includes a symmetric key whichmay be a cryptographic key used for both encryption and decryption ofdata. In an embodiment, the symmetric key 302 of the request 300 isprovided in the request 300 in plaintext form. It should be noted thatwhile the symmetric key is provided in the request 300 in plaintext formin some embodiments, the transfer of a request from a customer to aservice provider or generally between entities may involve variousprotocols to ensure security of any data in the request 300. Forexample, transmission of the request 300 may involve transport layersecurity (TLS) and/or another protocol such that the symmetric key 302is encrypted during transmission from one entity to the other. Further,while FIG. 3 shows a request 300 having a symmetric key 302 the request300 may include other data which is not illustrated in the figure. Suchdata as discussed above may include various request parameters,authentication information, data to be encrypted, and/or otherinformation.

In addition, while FIG. 3 shows a request with a key, as with allrequests described and illustrated herein, various other data may beprovided within the request, such as data to be operated on and/orvarious metadata including contextual information about the request andauthentication information usable to verify authenticity of the request.Various request parameters may also be included in the request. Forinstance, a request parameter may specify that server side encryption issupposed to be used to encrypt data using a key provided with therequest. If such a parameter is absent and/or indicates that server sideencryption is not to be used, the request may be processed withoutencryption being performed regardless of whether a key is included inthe request. Further, for requests submitted with electronic signatures,a parameter may specify which part of the request was used to generatean electronic signature. Such a parameter can indicate which part of arequest should be used for checking an electronic signature, therebyenabling requests to be modified after their generation, such as byadding data to be operated on during fulfillment of the request.Generally, requests are simplified in the present disclosure for thepurpose of illustration.

FIG. 4 shows an illustrative example of a process 400 which may be usedto transmit and receive a response to a request in accordance withvarious embodiments. The process 400 may be performed by any suitablesystem such as a device of a customer such as described above and belowin connection with FIG. 15. In an embodiment, the process 400 includesobtaining 402 a cryptographic key. The cryptographic key may be obtained402 in various ways in accordance with various embodiments. For example,in some embodiments the cryptographic key is obtained 402 by generatingthe cryptographic key. The cryptographic key may be generated forexample using a random number generator or a key derivation functionsuch as public key derivation function 2 (PPKDF2) or Bcrypt. Thecryptographic key may be obtained 402 in other ways as well. Forexample, the cryptographic key may be accessed from a data storagedevice. As another example, the cryptographic key may be a password,passphrase, or other type of passcode accessed from memory and/or inputby a user of a system performing the process 400. Generally, any way ofobtaining 402 a cryptographic key may be used.

With the cryptographic key having been obtained 402, the process 400 mayinclude generating 404 a request with the obtained cryptographic key;that is, generating a request that includes the obtained cryptographickey. The request may be generated by arranging data for the request in amanner suitable for transmission that is in a format processable by asystem to which the request will be submitted. Once generated 404, thegenerated request may be submitted 406. Submission 406 of the generatedrequest may be performed in any suitable manner such as by transmissionto an Internet protocol (IP) address of a webserver configured toreceive generated requests. Other operations may be performed, forexample, in some embodiments the request is generated from a uniformresource locator (URL). Communication with the domain name service (DNS)may occur to obtain an IP address for the system to which the generatedrequest is then submitted 406. Generally any way of submitting therequest may be performed.

Upon submission, a request may be processed by a system to which thegenerated request was submitted 406. Accordingly, the process 400 mayinclude receiving 408 a response to the request or the response may bean appropriately configured response in accordance with a protocol bywhich the request was submitted. It should be noted that not allembodiments require receipt of a response to the request. For example,some protocols may allow for the submission of requests withoutacknowledgement that the request has been received and/or fulfilled. Asan illustrative example, the request may be to store data. In someembodiments, upon submission it may be assumed that the request has beenprocessed or likely had been processed where acknowledgement ofprocessing of the request may not be required.

FIG. 5 shows an illustrative example of a process 500 for processing arequest where the request may be received such as described above andmay have been submitted in accordance with a process such as the process400 such as described above. The process 500 may be performed by anysuitable system such as by a device (e.g., server) operating to providea customer interface such as described above. In an embodiment, theprocess 500 includes receiving 502 a request with a cryptographic key.The request may be received 502 in various ways in accordance withvarious embodiments. For example as noted above, the request may besubmitted over a network in accordance with a communication protocol andthe request may therefore be received in accordance with such aprotocol. Generally the request may be received 502 in any suitable way.

Upon receipt of the request, the process 500 may include determining 504whether to fulfill the request. The determination 504 whether to fulfillthe request may be made in various ways in accordance with variousembodiments. For example as noted above, in some instances the requestmay be received with an electronic signature of the request.Accordingly, a determination may be made by determining whether thesignature is valid. Determination of whether the signature is valid maybe performed in various ways. For example, the system performing theprocess 500 may verify the signature itself or may transmit thesignature and request (or generally data signed to generate thesignature) to another system operable to verify the electronicsignature. Further as noted above, determining 504 whether to fulfillthe request may include performing a determination whether one or morepolicies would preclude fulfillment of the request. Generally any way bywhich a determination of whether to fulfill the request may beperformed.

In addition, while FIG. 5 and other processes illustrated herein showdeterminations whether to fulfill the request, in various embodiments,systems may fulfill all appropriately configured requests without theneed to have a valid electronic signature and/or compliance with policy.Returning to the embodiment illustrated in FIG. 5, if it is determined504 not to fill the request such as if a signature is invalid and/orpolicy precludes fulfillment of the request, the process 500 may includedenying 506 the request. Denying 506 the request may be performed invarious ways in accordance with various embodiments. For example, aresponse to the request may be provided that indicates that the requestis denied and/or that provides information why the request was denied.As another example, denying the request may simply be performed by nottaking any action. That is by not providing a response to the requestand simply not fulfilling the request. Generally any way in which therequest may not be fulfilled may be considered as denying the request.

If it is determined, however, to fulfill the request, the process 500may include extracting 508 a cryptographic key from the request. Theextracted cryptographic key may then be used 510 to perform one or morerequested cryptographic operations; that is to perform one or morecryptographic operations involved in fulfillment of the request. The oneor more cryptographic operations may vary in accordance with variousembodiments and in accordance with the type of request that wasreceived. In some embodiments for example, the one or more cryptographicoperations include encryption of data included with the request and/orencryption of other data. As another example, the one or morecryptographic operations may include decryption of data referenced byand/or provided in the request. Generally any type of cryptographicoperations such as key derivation and/or electronic signature generationand/or verification may be performed as part of the one or morecryptographic operations. Further, while various illustrativeembodiments described herein show a single cryptographic operation suchas encryption, multiple types of cryptographic operations may beperformed while fulfilling a single request. As an example, one or morekeys provided in a request may be used to encrypt data and generate anelectronic signature of the data and/or encrypted data where theelectronic signature can be used for later validation that the data hasbeen changed. Other variations are also considered as being within thescope of the present disclosure.

Upon performance of the one or more cryptographic operations, theprocess 500 may include providing 512 a response to the request. Theresponse may vary in accordance with the various embodiments and inaccordance with the type of request that was made. For example, if therequest was to retrieve data, the response may include data that wasretrieved and decrypted. If the request was to store data, the responsemay be an acknowledgement that the data has been stored. A check sum orother validation information may be provided with the response. At somepoint subsequent to performance of the one or more cryptographicoperations involved in fulfillment of the request, the process 500 mayinclude losing 514 access to the extracted cryptographic key whereaccess may be lost in various ways such as described above.

FIG. 6 is an illustrative example of a request 600 in accordance withvarious embodiments. As illustrated in FIG. 6, unlike the requestdescribed above in connection with FIG. 3, the request 600 includes acustomer public key 602 which may be a public key of a public/privatekey pair where the private key is held by or on behalf of the customer.As with other requests described herein, the request 600 may includeother data such as described above. The request 600 may be submittedsuch as described above in connection with FIG. 4.

FIG. 7 shows an illustrative example of a process 700 which may be usedto process a request that includes a customer public key such asdescribed above in connection FIG. 6. The process 700 may be performedby any suitable system, such as a system providing a customer interfacesuch as described above. As illustrated in FIG. 7, the process 700includes receiving 702 a PUT request with a customer public key; that isa PUT request (i.e., a request to store data) that has, as part of therequest, a customer public key. The request may be received 702 such asdescribed above and generally in any suitable manner. Upon receipt 702of the PUT request with the customer public key the process 700 mayinclude determining 704 whether to fulfill the request where thedetermination whether to fulfill the request may be made such asdescribed above. If it is determined 704 that the request should not befulfilled, the process 700 may include denying 706 the request such asdescribed above. If, however, it is determined 704 that the requestshould be fulfilled, the process 700 may include extracting 708 acustomer public key from the request for use. In an embodiment, theprocess 700 includes obtaining 710 an encryption key where theencryption key may be a symmetric key such as described above. Theencryption may be obtained 710 in any suitable manner such as describedabove. For example, the encryption key may be accessed from data storageor generated. The obtained 710 encryption key may be used 712 to encryptdata that was provided in the request or otherwise requested by therequest to be encrypted. The customer public key may be used 714 toencrypt (wrap) the encryption key. In this manner, the encryptedencryption key is decryptable using a private key corresponding to acustomer public key. Thus, if a provider performing the process 700 doesnot have access to the encrypted encryption key, the provider cannotdecrypt the encrypted encryption key.

The process 700 may also include storing 716 the encrypted data. Theencrypted data may be, for example, transmitted to a data storage systemfor persistent storage thereof. A response to the request may beprovided 718 where the response may include the encrypted encryptionkey. A system performing the process 700 may lose 720 access to theencryption key such as described above. In this manner, once a systemperforming the process 700 loses 720 access to the encryption key, thesystem no longer has the ability to decrypt the encrypted data andgenerally use of a private key corresponding to the customer public keyis necessary to legitimately (i.e., without guessing the key orotherwise obtaining access to the data in an unauthorized manner)decrypt the encrypted data by first decrypting the encryption key inorder to decrypt the decrypted data.

It should be noted, as with all processes described herein, variationsare considered as being within the scope of the present disclosure. Asan example, FIG. 7 shows a process for processing a PUT request wherethe request includes a customer public key. Such request can beprocessed in different ways in accordance with various embodiments. Insome embodiments for example, although use of a symmetric encryption keyis generally computationally more efficient, a customer public key maybe used to encrypt the data that was received in the request instead ofusing an encryption key that is then wrapped by the public key. In thismanner, the data is decryptable only by an entity having access to theprivate key corresponding to the customer public key, which in variousembodiments may be only the customer that submitted the request.

As another example of a variation considered as being within the scopeof the present disclosure, the encrypted encryption key may be storedwith the encrypted data and may or may not be transmitted in a responseto the request. In such an embodiment to decrypt the data, theencryption key may be accessed from storage provided to an entity ableto decrypt the encryption key (e.g., customer having a private keyusable to decrypt the encryption key) which may then provide thedecrypted encryption key back to enable decryption of the data. Forexample, a customer request to retrieve data may cause a provider totransmit an initial response with notification (including the encryptedencryption key) that the encryption key needs decrypting. The customermay decrypt the encryption key and provide the decrypted encryption keyback to the provider to enable the provider to decrypt the encrypteddata and provide the decrypted data to the customer. Other variations,including variations where ciphertext is provided to the customer fromthe provider along with an encrypted key usable to decrypt theciphertext, are also considered as being within the scope of the presentdisclosure. For embodiments where, for example, server side encryptionis used to PUT requests but client side encryption is used to obtainaccess to stored data, a provider may provide instructions for properlyprocessing data (e.g., by properly canonicalizing data for decryption)or may provide executable instructions in the form of a client libraryto ensure that decryption is performed correctly (i.e., to ensure thatdecryption is performed in a manner that will succeed in decrypting thedata).

FIG. 8 shows an illustrative example of a process 800 for obtaining datathat has been stored in encrypted form by another system such as by aprovider such as described above. The process 800 may be performed byany suitable system, such as by a device of a customer of a providersuch as described above. In an embodiment, the process 800 includesobtaining 802 an encrypted encryption key. For example, the encryptedencryption key may have been received pursuant to performance of theprocess 700 described above or a variation thereof. Obtaining theencrypted encryption key may include receiving the encrypted encryptionkey or accessing the encrypted encryption key from persistent datastorage. Generally the encrypted encryption key may be obtained 802 inany suitable manner.

A private key corresponding to a public key used to encrypt theencryption key may be used 804 to decrypt the encrypted encryption key.Once the decrypted encryption key has been obtained, the process 800 mayinclude generating 806 a GET request with the decrypted encryption keyand submitting (e.g., transmitting) 808 the generated GET request, suchas described above. A system that receives the GET request may processthe request by using the encryption key in the request to decrypt datathat was encrypted by the encryption key. A response may then bereceived 810 where the response may include appropriate information suchas data that has been decrypted using the decrypted encryption key thatwas provided in the GET request.

As with all processes described herein, variations of the process 800are considered to be within the scope of the present disclosure. Forexample, the encrypted encryption key may be obtained by accessing theencrypted encryption key from remote storage when the encryptedencryption key is stored with the data that is encrypted under theencrypted encryption key. As another example, in some embodiments theprocess 800 may include submitting a GET request that is fulfilled byproviding data encrypted under the encrypted encryption key. A systemperforming the process 800 may obtain the encrypted data and use thedecrypted encryption key to decrypt the encrypted data. In other words,the process 800 may be modified so that data is decrypted client-sideeven if the data was encrypted server-side.

FIG. 9 shows an illustrative example of various requests that mayinclude cryptographic keys that have been wrapped (i.e., encrypted) invarious forms in accordance with various embodiments. For example, FIG.9 shows an illustrative example of a request 902 having a symmetric key904 encrypted under a secret 906 shared with a provider where the secretshared with the provider may be another symmetric key shared between thecustomer and the provider. As another example, FIG. 9 shows an exampleof a request 908 that includes a symmetric key 910 encrypted under aprovider public key 912 which may be a public key corresponding to apublic private key pair of which the provider has access to acorresponding private key. Another request 914 includes a symmetric key916 encrypted under a secret 918 shared with a third party. That is anentity that is a third party to both a customer and a provider. As yetanother example, FIG. 9 shows a request 920 having a symmetric key 922encrypted under a public key 924 of a third party where the third partymay be a third party to a customer and provider. As noted, the requestsillustrated in FIG. 9 may also include additional information.

FIG. 10 shows an illustrative example of a process 1000 which may beused to submit a request in accordance with various embodiments. Theprocess 1000 may be performed by any suitable system such as by a systemof a customer of a provider such as described above. In an embodiment,the process 1000 includes obtaining 1002 a cryptographic key where thecryptographic key may be obtained 1002 such as described above. Theobtained cryptographic key may be used to generate 1004 a wrappedcryptographic key that is the obtained cryptographic key encrypted underanother key. Examples of wrapped cryptographic keys are described abovein connection with FIG. 9. The process 1000 may include generating 1006a request with the wrapped cryptographic key. That is the request may begenerated to include the wrapped cryptographic key. The generatedrequest may then be submitted 1008 such as described above. In variousembodiments, the process 1000 may also include receiving 1010 a responseto the request that was submitted 1008.

As noted above, numerous embodiments are considered as being within inthe scope of the present disclosure. In some embodiments, a customer andservice provider are able to interact to achieve data security withoutuse of a third party system to unwrap a key needed for cryptographicoperations. FIG. 11 accordingly shows an illustrative example of anenvironment 1100 in which various embodiments can be practiced. As withFIG. 1, as illustrated in FIG. 11, the environment 1100 includes acustomer 1102 that submits a request 1104 to a service provider 1106. Inthis example, the request 1104 includes an encryption key 1108 which, asindicated by the brackets surrounding the encryption key, is wrapped byanother key. The service provider 1106 has access to a key 1110 usableto unwrap the encryption key thereby enabling the service provider 1106to perform cryptographic operations using encryption key 1108.

FIG. 12 shows an illustrative example of a process 1200 which may beused to process a request that includes a wrapped cryptographic key. Theprocess 1200 may be performed by any suitable system such as by awebserver of a service provider 1106 described above in connection withFIG. 11. In an embodiment the process 1200 includes receiving 1202 arequest that has a wrapped cryptographic key. A determination may bemade 1204 whether to fulfill the request. If determined 1204 to notfulfill the request, the process 1200 may include denying 1206 therequest such as described above. If, however, it is determined 1204 thatthe request should be fulfilled, the process 1200 may include extracting1208 the wrapped cryptographic key from the request.

A key usable to unwrap the cryptographic key may be obtained 1210.Obtaining the key usable to unwrap the cryptographic key may beperformed in various ways in accordance with various embodiments. Forexample, the key usable to unwrap the wrapped cryptographic key may bestored by a system that performs the process 1200. An identifier of thekey usable to unwrap the wrapped cryptographic key may be used to locatethe key usable to unwrap the wrapped cryptographic key from other keyswhich may be stored by the system. The identifier may be provided in therequest that was received 1202 or may be otherwise determined such as byan association with an entity that submitted the request. Once the keyusable to unwrap the wrapped cryptographic key has been obtained 1210,the process 1200 may include using 1212 the obtained key to unwrap thewrapped cryptographic key. In this manner, an unwrapped cryptographickey is obtained. The unwrapped cryptographic key may be used 1214 toperform one or more cryptographic operations involved in fulfillment ofthe request that was received 1202. A response to the request may beprovided 1216 such as described above and access to the unwrappedcryptographic key may be lost 1218.

In some embodiments, as noted, involvement of a third party is part ofmaintaining data security. FIG. 13 accordingly shows an illustrativeexample of an environment 1300 with various embodiments can bepracticed. The environment 1300 as illustrated includes a customer 1302that submits a request 1304 to a service provider 1306 such as describedabove. Also as described above, the request 1304 may include anencryption key 1308 that is wrapped by another key such as describedabove in connection with FIG. 9. However, in the example of FIG. 13, asubsystem of the service provider 1306 that receives the request (or, insome embodiments, all subsystems of the service provider) may not haveaccess to a key usable to unwrap the encryption key 1308. Accordingly,the environment 1300 includes a key management system 1310 which hasaccess to a key 1312 usable to unwrap the wrapped encryption key 1308.The key management system 1310 may be any system operable to managecryptographic keys on behalf of one or more customers of the serviceprovider 1306.

The key management system 1310 may be implemented in various ways inaccordance with various embodiments. In some embodiments, the keymanagement system is a subsystem of the service provider 1306 which maybe implemented by, for instance, a hardware security module (HSM) hostedby the service provider 1306 or another type of security module thatsecurely stores cryptographic keys. In some embodiments, the keymanagement system 1310 is implemented as another service of the serviceprovider 1306 which may be one of several services provided by theservice provider 1306 and accessible to customer 1302 over a networksuch as described below. In some embodiments, the key management systemis a system such as described above, however, implemented by a thirdparty to the service provider 1306 and customer 1302. In suchembodiments, neither the customer 1302 nor the service provider 1306 hasaccess to the key usable to unwrap the encryption key 1308 unless thekey 1312 usable to unwrap the encryption key is shared with one or moreof the customer 1302 or service provider 1306. Other variations are alsoconsidered as being within the scope of the present disclosure. Forexample, the key management system 1310 may be implemented as part ofthe customer 1302 in some embodiments. Generally, the key managementsystem 1310 is a system with which the service provider 1306 mustcommunicate in order to unwrap or generally cause to have unwrapped theencryption key 1308 using the key 1312 usable to unwrap the encryptionkey. Communication between the service provider 1306 and the keymanagement system 1310 may occur over one or more networks and inaccordance with one or more appropriate network protocols. The networkmay be, for example, the Internet or any suitable network such asdescribed below.

FIG. 14 shows an illustrative example of a process 1400 which may beperformed to process a request that includes a wrapped encryption keysuch as described above in connection with FIG. 13. In an embodiment,the process 1400 includes receiving 1402 a request with the wrappedcryptographic key such as described above. As discussed above inconnection with other processes, a determination may be made 1404whether to fulfill the request, and if determined 1404 that the requestshould not be fulfilled the process 1400 may include denying 1406 therequest. If, however, it is determined 1404 that the request should befulfilled, the process 1400 may include extracting the wrappedcryptographic key from the request 1408. The wrapped cryptographic keymay be transmitted 1410 to an unwrapping system which may be a keymanagement system such as described above as in connection with FIG. 13and generally which may be a system with access to a key usable tounwrap the wrapped cryptographic key.

The wrapped cryptographic key may be transmitted in the form of arequest to the unwrapping system which is appropriately configured forfulfillment by the unwrapping system. For example, the request may beformatted in accordance with a format acceptable to the unwrappingsystem and the request may include information usable by the unwrappingsystem to determine whether to fulfill the request. Such information mayinclude, for example, authentication information used to authenticatethe request to the unwrapping system and/or the request that wasreceived 1402 with the wrapped cryptographic key. Other informationwhich may be used, for example, to determine whether fulfillment of therequest to the unwrapping system complies with one or more policies mayalso be provided or the information may be contextual information suchas described above. Additional information may include an identifier ofa key usable to unwrap the wrapped cryptographic key. Assuming that theunwrapping system fulfills the request that was transmitted 1410, theprocess 1400 may include receiving 1412 the unwrapped cryptographic keyfrom the unwrapping system. The unwrapped cryptographic key may be used1414 to perform one or more cryptographic operations involved infulfillment of the request that was received 1402. As response to therequest may be provided 1416 such as described above and access to theunwrapped cryptographic key may be lost 1418, such as described above.

As noted several times throughout the above disclosure, numerousvariations are considered as being within the scope of the presentdisclosure. For example, as discussed, numerous variations utilizesymmetric and/or asymmetric cryptographic primitives. Symmetric keyalgorithms may include various schemes for performing cryptographicoperations on data including block ciphers, stream ciphers and digitalsignature schemes. Example symmetric key algorithms include, but are notlimited to, the advanced encryption standard (AES), the data encryptionstandard (DES), triple DES (3DES), Serpent, Twofish, blowfish, CASTS,RC4 and the international data encryption algorithm (IDEA). Symmetrickey algorithms may also include those used to generate output of one wayfunctions and include, but are not limited to algorithms that utilizehash-based message authentication codes (HMACs), message authenticationcodes (MACs) in general, PBKDF2 and Bcrypt. Asymmetric key algorithmsmay also include various schemes for performing cryptographic operationson data. Example algorithms include, but are not limited to those thatutilize the Diffie-Hellman key exchange protocol, the digital signaturestandard (DSS), the digital signature algorithm, the ElGamal algorithm,various elliptic curve algorithms, password-authenticated key agreementtechniques, the pallier cryptosystem, the RSA encryption algorithm (PKCS#1), the Cramer-Shoup cryptosystem, the YAK authenticated key agreementprotocol, the NTRUEncrypt cryptosystem, the McEliece cryptosystem, andothers. Elliptic curve algorithms include the elliptic curveDiffie-Hellman (ECDH) key agreement scheme, the Elliptic CurveIntegrated Encryption Scheme (ECIES), the Elliptic Curve DigitalSignature Algorithm (ECDSA), the ECMQV key agreement scheme and the ECQVimplicit certificate scheme. Other algorithms and combinations ofalgorithms are also considered as being within the scope of the presentdisclosure.

In addition, as noted, various embodiments of the present disclosurerelate to the use of cryptographic keys included in requests to performvarious cryptographic operations. While the keys are discussed as beingused to perform the operations, it should be noted that variousembodiments of the present disclosure include those where keys aretransformed in some way before being used. As an example, in cases wherea key in a request is a passcode, the passcode may be transformed (e.g.,with a key derivation function) before being used to perform additionalcryptographic operations. Further, while the above disclosure discussesspecific types of keys (e.g., encryption keys) such keys may similarlybe transformed before use. Other variations include those where multiplekeys are provided in requests and request parameters and/or formattingof the request indicate how the multiple keys should be used.

Other variations considered as being within the scope of the presentdisclosure include embodiments that utilize pre-signed uniform resourcelocators (URLs). Referring to environments such as illustrated in FIG. 1that include a customer of a service provider, a customer canpre-generate URLs that include an electronic signature of a portion ofthe URL and/or other information, such as a cryptographic key. Thecustomer may provide the URL to another entity and the other entity canutilize the URL to submit requests to the service provider to cause theservice provider to perform one or more operations under theauthorization of the customer. The service provider can receive arequest submitted with the URL, verify the electronic signature, andperform the one or more operations using a key provided in the URL. Inthis manner, various conveniences involving server-side encryption anddecryption with customer control over keys and provider inability toaccess keys except when necessary are achieved. The use of pre-signedURLs and variations thereof are discussed in detail in concurrentlyfiled U.S. patent application Ser. No. 14/037,282, entitled “ResourceLocators With Keys,” which is incorporated by reference in its entirety.

FIG. 15 illustrates aspects of an example environment 1500 forimplementing aspects in accordance with various embodiments. As will beappreciated, although a web-based environment is used for purposes ofexplanation, different environments may be used, as appropriate, toimplement various embodiments. The environment includes an electronicclient device 1502, which can include any appropriate device operable tosend and receive requests, messages or information over an appropriatenetwork 1504 and convey information back to a user of the device.Examples of such client devices include personal computers, cell phones,handheld messaging devices, laptop computers, tablet computers, set-topboxes, personal data assistants, embedded computer systems, electronicbook readers and the like. The network can include any appropriatenetwork, including an intranet, the Internet, a cellular network, alocal area network or any other such network or combination thereof.Components used for such a system can depend at least in part upon thetype of network and/or environment selected. Protocols and componentsfor communicating via such a network are well known and will not bediscussed herein in detail. Communication over the network can beenabled by wired or wireless connections and combinations thereof. Inthis example, the network includes the Internet, as the environmentincludes a web server 1506 for receiving requests and serving content inresponse thereto, although for other networks an alternative deviceserving a similar purpose could be used as would be apparent to one ofordinary skill in the art.

The illustrative environment includes at least one application server1508 and a data store 1510. It should be understood that there can beseveral application servers, layers or other elements, processes orcomponents, which may be chained or otherwise configured, which caninteract to perform tasks such as obtaining data from an appropriatedata store. Servers, as used herein, may be implemented in various ways,such as hardware devices or virtual computer systems. In some contexts,servers may refer to a programming module being executed on a computersystem. As used herein the term “data store” refers to any device orcombination of devices capable of storing, accessing and retrievingdata, which may include any combination and number of data servers,databases, data storage devices and data storage media, in any standard,distributed or clustered environment. The application server can includeany appropriate hardware and software for integrating with the datastore as needed to execute aspects of one or more applications for theclient device, handling some (even a majority) of the data access andbusiness logic for an application. The application server may provideaccess control services in cooperation with the data store and is ableto generate content such as text, graphics, audio and/or video to betransferred to the user, which may be served to the user by the webserver in the form of HyperText Markup Language (“HTML”), ExtensibleMarkup Language (“XML”) or another appropriate structured language inthis example. The handling of all requests and responses, as well as thedelivery of content between the client device 1502 and the applicationserver 1508, can be handled by the web server. It should be understoodthat the web and application servers are not required and are merelyexample components, as structured code discussed herein can be executedon any appropriate device or host machine as discussed elsewhere herein.Further, operations described herein as being performed by a singledevice may, unless otherwise clear from context, be performedcollectively by multiple devices, which may form a distributed system.

The data store 1510 can include several separate data tables, databasesor other data storage mechanisms and media for storing data relating toa particular aspect of the present disclosure. For example, the datastore illustrated may include mechanisms for storing production data1512 and user information 1516, which can be used to serve content forthe production side. The data store also is shown to include a mechanismfor storing log data 1514, which can be used for reporting, analysis orother such purposes. It should be understood that there can be manyother aspects that may need to be stored in the data store, such as pageimage information and access rights information, which can be stored inany of the above listed mechanisms as appropriate or in additionalmechanisms in the data store 1510. The data store 1510 is operable,through logic associated therewith, to receive instructions from theapplication server 1508 and obtain, update or otherwise process data inresponse thereto. In one example, a user, through a device operated bythe user, might submit a search request for a certain type of item. Inthis case, the data store might access the user information to verifythe identity of the user and can access the catalog detail informationto obtain information about items of that type. The information then canbe returned to the user, such as in a results listing on a web page thatthe user is able to view via a browser on the user device 1502.Information for a particular item of interest can be viewed in adedicated page or window of the browser. It should be noted, however,that embodiments of the present disclosure are not necessarily limitedto the context of web pages, but may be more generally applicable toprocessing requests in general, where the requests are not necessarilyrequests for content.

Each server typically will include an operating system that providesexecutable program instructions for the general administration andoperation of that server and typically will include a computer-readablestorage medium (e.g., a hard disk, random access memory, read onlymemory, etc.) storing instructions that, when executed by a processor ofthe server, allow the server to perform its intended functions. Suitableimplementations for the operating system and general functionality ofthe servers are known or commercially available and are readilyimplemented by persons having ordinary skill in the art, particularly inlight of the disclosure herein.

The environment in one embodiment is a distributed computing environmentutilizing several computer systems and components that areinterconnected via communication links, using one or more computernetworks or direct connections. However, it will be appreciated by thoseof ordinary skill in the art that such a system could operate equallywell in a system having fewer or a greater number of components than areillustrated in FIG. 15. Thus, the depiction of the system 1500 in FIG.15 should be taken as being illustrative in nature and not limiting tothe scope of the disclosure.

The various embodiments further can be implemented in a wide variety ofoperating environments, which in some cases can include one or more usercomputers, computing devices or processing devices which can be used tooperate any of a number of applications. User or client devices caninclude any of a number of general purpose personal computers, such asdesktop, laptop or tablet computers running a standard operating system,as well as cellular, wireless and handheld devices running mobilesoftware and capable of supporting a number of networking and messagingprotocols. Such a system also can include a number of workstationsrunning any of a variety of commercially-available operating systems andother known applications for purposes such as development and databasemanagement. These devices also can include other electronic devices,such as dummy terminals, thin-clients, gaming systems and other devicescapable of communicating via a network.

Various embodiments of the present disclosure utilize at least onenetwork that would be familiar to those skilled in the art forsupporting communications using any of a variety ofcommercially-available protocols, such as Transmission ControlProtocol/Internet Protocol (“TCP/IP”), protocols operating in variouslayers of the Open System Interconnection (“OSI”) model, File TransferProtocol (“FTP”), Universal Plug and Play (“UpnP”), Network File System(“NFS”), Common Internet File System (“CIFS”) and AppleTalk. The networkcan be, for example, a local area network, a wide-area network, avirtual private network, the Internet, an intranet, an extranet, apublic switched telephone network, an infrared network, a wirelessnetwork and any combination thereof.

In embodiments utilizing a web server, the web server can run any of avariety of server or mid-tier applications, including Hypertext TransferProtocol (“HTTP”) servers, FTP servers, Common Gateway Interface (“CGP”)servers, data servers, Java servers and business application servers.The server(s) also may be capable of executing programs or scripts inresponse to requests from user devices, such as by executing one or moreweb applications that may be implemented as one or more scripts orprograms written in any programming language, such as Java®, C, C# orC++, or any scripting language, such as Perl, Python or TCL, as well ascombinations thereof. The server(s) may also include database servers,including without limitation those commercially available from Oracle®,Microsoft®, Sybase® and IBM®.

The environment can include a variety of data stores and other memoryand storage media as discussed above. These can reside in a variety oflocations, such as on a storage medium local to (and/or resident in) oneor more of the computers or remote from any or all of the computersacross the network. In a particular set of embodiments, the informationmay reside in a storage-area network (“SAN”) familiar to those skilledin the art. Similarly, any necessary files for performing the functionsattributed to the computers, servers or other network devices may bestored locally and/or remotely, as appropriate. Where a system includescomputerized devices, each such device can include hardware elementsthat may be electrically coupled via a bus, the elements including, forexample, at least one central processing unit (“CPU” or “processor”), atleast one input device (e.g., a mouse, keyboard, controller, touchscreen or keypad) and at least one output device (e.g., a displaydevice, printer or speaker). Such a system may also include one or morestorage devices, such as disk drives, optical storage devices andsolid-state storage devices such as random access memory (“RAM”) orread-only memory (“ROM”), as well as removable media devices, memorycards, flash cards, etc.

Such devices also can include a computer-readable storage media reader,a communications device (e.g., a modem, a network card (wireless orwired), an infrared communication device, etc.) and working memory asdescribed above. The computer-readable storage media reader can beconnected with, or configured to receive, a computer-readable storagemedium, representing remote, local, fixed and/or removable storagedevices as well as storage media for temporarily and/or more permanentlycontaining, storing, transmitting and retrieving computer-readableinformation. The system and various devices also typically will includea number of software applications, modules, services or other elementslocated within at least one working memory device, including anoperating system and application programs, such as a client applicationor web browser. It should be appreciated that alternate embodiments mayhave numerous variations from that described above. For example,customized hardware might also be used and/or particular elements mightbe implemented in hardware, software (including portable software, suchas applets) or both. Further, connection to other computing devices suchas network input/output devices may be employed.

Storage media and computer readable media for containing code, orportions of code, can include any appropriate media known or used in theart, including storage media and communication media, such as, but notlimited to, volatile and non-volatile, removable and non-removable mediaimplemented in any method or technology for storage and/or transmissionof information such as computer readable instructions, data structures,program modules or other data, including RAM, ROM, Electrically ErasableProgrammable Read-Only Memory (“EEPROM”), flash memory or other memorytechnology, Compact Disc Read-Only Memory (“CD-ROM”), digital versatiledisk (DVD) or other optical storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices or any othermedium which can be used to store the desired information and which canbe accessed by the system device. Based on the disclosure and teachingsprovided herein, a person of ordinary skill in the art will appreciateother ways and/or methods to implement the various embodiments.

The specification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense. It will, however, beevident that various modifications and changes may be made thereuntowithout departing from the broader spirit and scope of the invention asset forth in the claims.

Other variations are within the spirit of the present disclosure. Thus,while the disclosed techniques are susceptible to various modificationsand alternative constructions, certain illustrated embodiments thereofare shown in the drawings and have been described above in detail. Itshould be understood, however, that there is no intention to limit theinvention to the specific form or forms disclosed, but on the contrary,the intention is to cover all modifications, alternative constructionsand equivalents falling within the spirit and scope of the invention, asdefined in the appended claims.

The use of the terms “a” and “an” and “the” and similar referents in thecontext of describing the disclosed embodiments (especially in thecontext of the following claims) are to be construed to cover both thesingular and the plural, unless otherwise indicated herein or clearlycontradicted by context. The terms “comprising,” “having,” “including”and “containing” are to be construed as open-ended terms (i.e., meaning“including, but not limited to,”) unless otherwise noted. The term“connected,” when unmodified and referring to physical connections, isto be construed as partly or wholly contained within, attached to orjoined together, even if there is something intervening. Recitation ofranges of values herein are merely intended to serve as a shorthandmethod of referring individually to each separate value falling withinthe range, unless otherwise indicated herein and each separate value isincorporated into the specification as if it were individually recitedherein. The use of the term “set” (e.g., “a set of items”) or “subset”unless otherwise noted or contradicted by context, is to be construed asa nonempty collection comprising one or more members. Further, unlessotherwise noted or contradicted by context, the term “subset” of acorresponding set does not necessarily denote a proper subset of thecorresponding set, but the subset and the corresponding set may beequal.

Conjunctive language, such as phrases of the form “at least one of A, B,and C,” or “at least one of A, B and C,” unless specifically statedotherwise or otherwise clearly contradicted by context, is otherwiseunderstood with the context as used in general to present that an item,term, etc., may be either A or B or C, or any nonempty subset of the setof A and B and C. For instance, in the illustrative example of a sethaving three members used in the above conjunctive phrase, “at least oneof A, B, and C” and “at least one of A, B and C” refers to any of thefollowing sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus,such conjunctive language is not generally intended to imply thatcertain embodiments require at least one of A, at least one of B and atleast one of C to each be present.

Operations of processes described herein can be performed in anysuitable order unless otherwise indicated herein or otherwise clearlycontradicted by context. Processes described herein (or variationsand/or combinations thereof) may be performed under the control of oneor more computer systems configured with executable instructions and maybe implemented as code (e.g., executable instructions, one or morecomputer programs or one or more applications) executing collectively onone or more processors, by hardware or combinations thereof. The codemay be stored on a computer-readable storage medium, for example, in theform of a computer program comprising a plurality of instructionsexecutable by one or more processors. The computer-readable storagemedium may be non-transitory.

The use of any and all examples, or exemplary language (e.g., “such as”)provided herein, is intended merely to better illuminate embodiments ofthe invention and does not pose a limitation on the scope of theinvention unless otherwise claimed. No language in the specificationshould be construed as indicating any non-claimed element as essentialto the practice of the invention.

Preferred embodiments of this disclosure are described herein, includingthe best mode known to the inventors for carrying out the invention.Variations of those preferred embodiments may become apparent to thoseof ordinary skill in the art upon reading the foregoing description. Theinventors expect skilled artisans to employ such variations asappropriate and the inventors intend for embodiments of the presentdisclosure to be practiced otherwise than as specifically describedherein. Accordingly, the scope of the present disclosure includes allmodifications and equivalents of the subject matter recited in theclaims appended hereto as permitted by applicable law. Moreover, anycombination of the above-described elements in all possible variationsthereof is encompassed by the scope of the present disclosure unlessotherwise indicated herein or otherwise clearly contradicted by context.

All references, including publications, patent applications and patents,cited herein are hereby incorporated by reference to the same extent asif each reference were individually and specifically indicated to beincorporated by reference and were set forth in its entirety herein.

What is claimed is:
 1. A computer-implemented method, comprising:obtaining an encrypted cryptographic key that encodes a cryptographickey; providing, to a computer system of a service provider, a requestover a network, the request: including the encrypted cryptographic key;and specifying data upon which to perform a cryptographic operationusing the cryptographic key; and obtaining, from the computer system, aresponse indicating fulfillment of the request to perform thecryptographic operation on the data, wherein fulfillment of the requestincludes decryption of the encrypted cryptographic key by anotherentity.
 2. The computer-implemented method of claim 1, wherein thecryptographic key is a member of an asymmetric key-pair.
 3. Thecomputer-implemented method of claim 1, wherein the cryptographic key isusable to authenticate a requestor.
 4. The computer-implemented methodof claim 1, wherein the fulfillment of the request includes encryptionof the data using the cryptographic key and another key.
 5. Thecomputer-implemented method of claim 1, wherein the encryptedcryptographic key was encrypted using a public key of a customer of theservice provider.
 6. The computer-implemented method of claim 1, whereinobtaining the cryptographic key includes generating the cryptographickey using a random number generator or a key derivation function.
 7. Thecomputer-implemented method of claim 1, wherein the response includes anassurance that the computer system has lost access to the cryptographickey.
 8. The computer-implemented method of claim 1, wherein thespecified data has been encrypted by the cryptographic key.
 9. Thecomputer-implemented method of claim 1, wherein the encryptedcryptographic key is decryptable using a private key corresponding topublic key of a customer of the service provider.
 10. A system,comprising: one or more processors; and memory including instructionsthat, if executed by the one or more processors, cause the system to:obtain an encoding of a cryptographic key in a form of an encrypted key;provide, to a service provider over a network, a request whosefulfillment involves performing a cryptographic operation on data usingthe cryptographic key; and obtain, from the service provider, a responsethat indicates the fulfillment of the request, wherein fulfillment ofthe request is based at least in part on the encrypted cryptographic keybeing provided to another entity by the service provider.
 11. The systemof claim 10, wherein the cryptographic key is a passcode of a user ofthe system.
 12. The system of claim 10, wherein the request includes anelectronic signature usable to authenticate a requestor.
 13. The systemof claim 10, wherein the cryptographic operation is an encryptionoperation.
 14. The system of claim 13, wherein the fulfillment furtherinvolves performing the encryption operation on the data using thecryptographic key and another key.
 15. The system of claim 10, whereinthe response includes an indication of the cryptographic key beingerased from a volatile memory of the system.
 16. The system of claim 10,wherein the cryptographic key is a symmetric key.
 17. A non-transitorycomputer-readable storage medium that includes executable instructionsthat, if executed by one or more processors of a first computer system,cause the first computer system to: provide, over a network to a secondcomputer system, a request to perform a cryptographic operation, therequest: specifying first data; and including information that includesan encoding of a cryptographic key in the form of an encryptedcryptographic key, the cryptographic key usable to perform thecryptographic operation on the first data to produce second data; andobtain, in response to the request, the second data, wherein the seconddata is produced as a result of the encrypted cryptographic key beingprovided to a third computer system for decryption.
 18. Thenon-transitory computer-readable storage medium of 17, wherein theexecutable instructions include instructions that cause the firstcomputer system to electronically sign the request using a differentcryptographic key from the cryptographic key included in the request.19. The non-transitory computer-readable storage medium of 17, whereinthe cryptographic operation is a decryption operation.
 20. Thenon-transitory computer-readable storage medium of 17, wherein: therequest includes the first data; the first data has been encrypted usingthe cryptographic key prior to being provided to the second computersystem; and the cryptographic key is usable to service the request.